1. Field of the Invention
This invention relates to a method and apparatus for initializing the configuration of a crypto module and, more particularly, to a method and apparatus for initializing the configuration of the cryptographic coprocessor of a general-purpose computer.
2. Description of the Related Art
Cryptographic functions of a general-purpose computer such as data encryption, digital signature processing and key management have often been performed by a cryptographic coprocessor, both for performance reasons and because of the special security problems posed by the cryptographic environment. One example of a cryptographic coprocessor in an IBM S/390 environment is the
Integrated Cryptographic Facility (ICRF). ICRF was used with processors employing bipolar technology. With the migration to CMOS processor technology, as exemplified by the S/390 Parallel Enterprise Server, new technological challenges have arisen in the design of a cryptographic coprocessor that is optimized for a CMOS setting.
It is desirable to install a cryptographic processor as part of a basic machine and ship these machines worldwide without export restrictions. It is also desirable to keep the number of hardware part numbers and versions to a minimum. To do this requires that the cryptographic functions on the cryptographic processor be disabled until some external form of enabling is supplied. This enabling function must be secure, must be unique for each cryptographic processor, and must provide granularity of enabling. That is:
In addition, examination of the export requirements, customer requirements, and marketing segments shows that there are a great many different crypto configurations that may need to be shipped. This includes, but is not limited to, machines with and without the commercial data masking facility (CDMF); with and without full DES; authentication-only systems; European versus USA and Canada; 512-bit versus 1024-bit RSA; and 512-bit versus 1024-bit Diffie-Hellman (DH) key exchange. These may need to be separately controlled for protection of signature objects and receive objects. There may also be certain low-security functions, such as clear master key entry, which some customers may need and others may require be disabled. There may be additional bits in the crypto configuration control, such as test mode or enablement of various checking schemes, which may need to be set. It becomes clear that it is not practical to generate individual setup sequences for such a large number of different crypto configurations as part of the manufacturing process.
In addition to the problem of many possible configurations, there may also be the problem of resale of a cryptographic processor. Consider that a customer may desire to sell his system containing a cryptographic processor to another owner. What happens if it turns out that under the export controls, the new owner is not entitled to all the functions enabled for the first customer? If the second customer has access to the information used to load the configuration for the first customer, this can be replayed to enable the same configuration.
Finally, a cryptographic processor must be initialized with customer-supplied information, including information to identify public keys of authorities, which of these are authorized to add or remove authorities, which are authorized to change signature requirements, enter key parts, enable or disable crypto, or set the special security mode. The authorized customer program must be permitted to load this information, but at the same time, programs not authorized must be prevented from loading incorrect information into the crypto module.